I think we've discussed this previously, but it could be worth bringing up another time. If the context is canceled, wouldn't it make sense to immediately return a cancellation error from wait_blocking, even if the provided closure runs to completion (because we cannot stop it)?

I haven't changed the semantics - scope waits for all tasks to finish no matter if they ignore the ctx cancellation or not.

afaict, our use cases for this function are about running a blocking function in non-blocking context rather than allowing things to run after context cancellation. In general it is a bug to spawn a blocking context-unaware method from within a scope (it is against structured concurrency principle), so I don't want to facilitate such an antipattern (with the current semantics a context-unaware function should cause a deadlock which will propagate up the stack and should be relatively easy to notice). In case of rocksdb access it is ok-ish, because it is expected to finish in a bounded amount of time (in fact all filesystem accesses in unix don't have a proper notion of cancellability).